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(54) Method and system for using real-time traffic broadcasts with navigation systems 



(57) A system and method are disclosed that allow 
a navigation system that uses a geographic database 
to also use the data in traffic messages broadcast by a 
traffic broadcast system. One aspect of a present sys- 
tem and method includes the formation, storage, and 
use of location reference data records in a geographic 
database used by a navigation system. These location 
reference data records identify certain other kinds of da- 
ta records that represent physical geographic features, 
such as data records that represent segments of roads, 
as being associated with certain location reference 
numbers. These location reference records may be in- 
cluded in a geographic database installed in the vehicle 
or may be provided to vehicles via a wireless communi- 



cation link. Another aspect of a present system and 
method includes the formation, storage, and use of one 
or more indices that relate location reference numbers 
used by a traffic broadcast system to location reference 
records in a geographic database used by the naviga- 
tion system. Another aspect of a present system and 
method is the formation, storage, and use of data that 
identify, for each location reference number, the imme- 
diately previous and the immediately next location ref- 
erence number. Still another aspect of a present system 
and method includes the programming, and methods of 
use thereof, that query the geographic database and re- 
turn the data entities associated with certain identified 
location reference numbers. 
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Description 

BACKGROUND OF THE INVENTION 



[0001] The present invention relates to a system and 
method for using real-time broadcasts of traffic and road 
conditions in a navigation system, and more particularly, 
the present invention relates to a system and method 
that facilitates and implements the use and coordination 
of traffic broadcast data in a navigation system that uses 
a geographic database. 

[0002] In some regional and metropolitan areas and 
countries, systems have been implemented that broad- 
cast up-to-the-minute reports of traffic and road condi- 
tion information. These systems broadcast traffic and 
road condition information on a continuous, periodic, or 
frequently occurring basis. These broadcasts can be re- 
ceived by receivers installed on-board vehicles that trav- 
el in the region. The on-board receivers decode the 
broadcast reports and make the information in the re- 
ports available to the vehicle driver. 
[0003] These traffic report broadcast systems have 
several advantages over the simple broadcasting of traf- 
fic reports over radio stations. For example, with these 
traffic broadcasting systems, a driver can obtain the re- 
port more quickly. The driver does not have to wait until 
a radio station broadcasts a traffic report. Another ad- 
vantage of these traffic broadcasting systems is that the 
driver does not have to listen to descriptions of traffic 
conditions for areas remote from his or her location. An- 
other advantage of traffic broadcast systems is that 
more detailed and possibly more up-to-date information 
can be provided. 

[0004] In these types of systems, the traffic informa- 
tion that is broadcast conforms to one or more pre-es- 
tablished specifications or formats. These specifications 
or formats are used by the on-board receivers in the ve- 
hicles that travel in the region to decode the traffic report 
messages. 

[0005] One system for broadcasting real-time traffic 
and road conditions is the Radio Data System-Traffic 
Message Channel ("RDS-TMC"). The RDS-TMC sys- 
tem is used in some European countries. The RDS-TMC 
system is described in various publications, including 
"Radio Data System, CENELEC END50067:1996, 
Specification of the Radio Data System." The RDS-TMC 
system broadcasts traffic messages to vehicles using 
an FM station data channel. RDS-TMC messages are 
broadcast regularly or at varying intervals depending on 
the priority of the events. Similar or identical systems 
are being used or are being planned in other countries 
and regions. 

[0006] For purposes of identifying locations of traffic 
congestion, the traffic and road condition broadcast sys- 
tems in use today, as well as thos planned for the fu- 
ture, assign codes to locations in a covered region. For 
example, in the RDS-TMC system, location reference 
codes are assigned to specific locations along roads in 



a covered geographic region. The locations may be in- 
tersections, interchanges, or portions of roads. Then, 
data messages ar broadcast identifying traffic condi- 
tions relating to these locations. In general, these loca- 
5 tions relate to heavily traveled roads, such as express- 
ways and main roads. 

[0007] Another, separate technology that has devel- 
oped to assist drivers is the vehicle navigation system. 
Vehicle navigation systems provide various navigating 
w features to drivers of vehicles, as well as others. The 
features provided by a vehicle navigation system differ 
from those provided by a traffic broadcast system. For 
example, a navigation system can calculate a specific 
route for a driver. The route calculated for the driver can 
15 begin at any street location in a covered geographic ar- 
ea and have a destination located at any other street 
location in the covered geographic region. The vehicle 
navigation system may also provide route guidance to 
the driver. The route guidance function can also be spe- 
20 cific to the route calculated for the driver. The route guid- 
ance function may provide maneuvering instructions, 
audibly or visually, to the driver as the route is being fol- 
lowed. The navigation system may also provide other 
features, such as finding one or more destinations of a 
25 particular type within a given search area, such as all 
the Italian restaurants within two miles of a present po- 
sition of the vehicle. In order to provide these kinds of 
functions, the navigation system uses a detailed geo- 
graphic database, either located in the vehicle or acces- 
30 sible over a wireless communication link. 

[0008] Both traffic broadcast systems and navigation 
systems can provide drivers with valuable features. 
However, even additional useful features could be pro- 
vided if the data in the traffic broadcast reports could be 
35 used in conjunction with the navigation system features. 
For example, it would be advantageous if the data in the 
traffic messages could be utilized when calculating a 
route using the route calculation function in the naviga- 
tion system. Unfortunately, the data in the reports broad- 
40 cast by traffic broadcast systems, such as the RDS- 
TMC system, do not relate to the data used by the nav- 
igation system. For example, the location numbers as- 
signed by the traffic broadcast system authorities, do not 
directly relate to any physical feature represented by the 
45 data records in the geographic database used by a nav- 
igation system. 

[0009] Accordingly, there exists a need for using 
broadcast traffic reports in conjunction with a vehicle 
navigation system that uses a geographic database. 

50 

SUMMARY OF THE INVENTION 



[0010] To address the above concerns, a system and 
method are provided that allow a navigation system that 
55 uses a geographic database to also use the data in traf- 
fic messag s broadcast by a traffic broadcast syst m. 
One aspect of a present mbodiment includes the for- 
mation, storag , and use of location referenc data 
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records in a geographic database used by a navigation 
system. These location reference data records identify 
certain other kinds of data records that represent phys- 
ical geographic features, such as data records that rep- 
resent segments of roads, as being associated with cer- 
tain location reference numbers. These location refer- 
ence data records may be included in a geographic da- 
tabase installed in the vehicle or may be provided to ve- 
hicles via a wireless communication link. 
[0011] Another aspect of a present embodiment in- 
cludes the formation, storage, and use of one or more 
indices that relate location reference numbers used by 
a traffic broadcast system to location reference data 
records in a geographic database used by the naviga- 
tion system. 

[0012] Another aspect of a present embodiment is the 
formation, storage, and use of location reference data 
records in parcels. 

[0013] Still another aspect of a present embodiment 
is the formation, storage, and use of data that identifies, 
for each location reference number, the immediately 
previous and the immediately next location reference 
number. 

[0014] Still another aspect of a present embodiment 
includes the programming, and methods of use thereof, 
that query the geographic database and return the data 
entities associated with certain identified location refer- 
ence numbers. 

[0015] Another aspect of a present embodiment is the 
ability to support multiple different types of traffic mes- 
sage systems using a geographic database. 
[0016] Another aspect of a present embodiment in- 
cludes a geographic database that supports use of real 
time traffic data that are transmitted to a navigation ap- 
plication that uses the geographic database, wherein 
the means by which the real time traffic data are trans- 
mitted include forms of wireless transmission, such as 
broadcasting and direct transmission, as well as forms 
of non-wireless transmission, such as telephone and 
data lines. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0017] Figure 1 is diagram illustrating components of 
a traffic broadcast system in a geographic region. 
[0018] Figure 2 is a block diagram illustrating compo- 
nents of the traffic broadcast system and one of the ve- 
hicles with an on-board navigation system, as shown in 
Figure 1. 

[0019] Figure 3 is a diagram illustrating data compo- 
nents included in one of the traffic messages shown in 
Figure 2. 

[0020] Figure 4 illustrates a map illustrating a geo- 
graphic region which may correspond to the region 
shown in Figure 1. 

[0021] Figur 5 is an expanded view of a portion of 
the map of Figur 4. 

[0022] Figure 6 is a block diagram showing an organ- 



ization by type of the geographic database in Figure 2. 
[0023] Figure 7 is a block diagram showing an organ- 
ization by layer of the routing type of th geographic da- 
tabase shown in Figure 6. 

5 [0024] Figure 8 is a block diagram showing an organ- 
ization of the geographic database shown in Figure 2. 
[0025] Figure 9 is an illustration of a portion of a road- 
way along which intersections have been assigned lo- 
cation reference numbers which are used by the traffic 

10 broadcast system of Figure 1 . 

[0026] Figure 1 0 is a diagram of the components of a 
location reference key formed to relate location refer- 
ence numbers as shown in Figure 9 to data included in 
the geographic database shown in Figures 2 and 8. 

15 [0027] Figure 11 is a block diagram illustrating the 
components that form the location reference record. 
[0028] Figure 1 2 is a block diagram illustration the or- 
ganization of data in one of the parcels containing loca- 
tion reference data records shown in Figure 8. 

20 [0029] Figure 1 3 is a block diagram illustrating the or- 
ganization of indices for the location reference records. 
[0030] Figure 14 is a flow chart illustrating the steps 
performed by programming in a navigation system of 
Figure 2 that uses traffic broadcast message data in 

25 conjunction with geographic data. 

[0031] Figure 1 5 is a flow chart showing the steps per- 
formed in a first example that uses the programming 
steps shown in Figure 14. 

[0032] Figure 1 6 is a flow chart showing the steps per- 
30 formed in a second example that uses the programming 
steps shown in Figure 14. 

[0033] Figure 17 is a block diagram illustrating an al- 
ternative embodiment for utilizing traffic message data 
with a navigation system. 

35 

DETAILED DESCRIPTION OF THE PRESENTLY 
PREFERRED EMBODIMENTS 

L TRAFFIC BROADCAST SYSTEM - OVERVIEW 

40 

[0034] Figure 1 is diagram illustrating a region 1 0. The 
region 10 may be a metropolitan area, such as the New 
York metropolitan area, the Los Angeles metropolitan 
area, or any other metropolitan area. Alternatively, the 

45 region 1 0 may be a state, province, or country, such as 
California, Illinois, France, England, or Germany. Alter- 
natively, the geographic region 10 can be combination 
of one or more metropolitan areas, states, countries and 
so on. Located in the region 10 is a road network 12. 

so [0035] A traffic broadcast system 20 is located in the 
region 10. The traffic broadcast system 20 broadcasts 
data 50 regarding the traffic and road conditions in the 
region 10. The traffic broadcast system 20 may be op- 
erated by a government organization or may be privately 

55 operated. In one embodiment, the traffic broadcasting 
system 20 conforms to th RDS (Radio Data Syst m) 
standard, although alternative systems can be used. 
[0036] Vehicles 11(A), 11(B), 11(C)...11(n) travel on 
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the road network 12 in the region 10. The vehicles 11 
may include cars or trucks. Some or all of the vehicles 
11 include suitabl equipment that enables them to re- 
ceiv th traffic and road condition data broadcast by 
the traffic broadcast system 20. 
[0037] The data 50 broadcast from the traffic broad- 
cast system 20 may also be received and used in sys- 
tems that are not installed in vehicles (e.g., "non-vehi- 
cles 80°). These non-vehicles 80 may include worksta- 
tions, personal computers, personal digital assistants, 
networks, pagers, televisions, radio receivers, tele- 
phones, and so on. The non-vehicle 80 that receive the 
data 50 may obtain them in the same manner as the 
vehicles, i.e., by broadcast. Alternatively, the non-vehi- 
cles 80 may receive the data 50 by other means, such 
as over telephone lines, over the Internet, via cable, and 
so on. The systems in the vehicles 11 or in the non-ve- 
hicles 80 that receive the traffic data 50 may include var- 
ious different platforms. 

[0038] Figure 2 shows diagrammatically the compo- 
nents of the traffic information broadcast system 20 and 
one of the vehicles 11 in Figure 1 . The traffic information 
broadcast system 20 provides for the collection of data 
relating to traffic and road conditions, the analysis and 
organization of these collected data, the formatting of 
the analyzed data into traffic messages, and the trans- 
mission of these traffic messages to the vehicles 11 in 
the region 10 on a regular and continuing basis. 
[0039] The traffic broadcast system 20 uses various 
means 22 to obtain information about traffic and road 
conditions. These means 22 may include sensors locat- 
ed in or near the roads in the road network 12, aerial 
sensors, sensors in vehicles 11, radar, as well as other 
technologies. 

[0040] The traffic broadcast system 20 includes 
equipment and programming 20(1 ) for collecting the da- 
ta relating to traffic and road conditions in the region 10 
from the various sensors 22. This equipment and pro- 
gramming 20(1) includes, for example, various commu- 
nications links (including wireless links), receivers, data 
storage devices, programming that saves the collected 
data, programming that logs data collection times and 
locations, and so on. The traffic broadcast system 20 
includes equipment and programming 20(2) for assem- 
bling, organizing, analyzing and formatting the collected 
traffic and road condition data. This programming and 
equipment 20(2) includes storage devices, program- 
ming that statistically analyzes the collected data for po- 
tential errors, programming that organizes the collected 
data, programming that uses the data to prepare mes- 
sages in one or more appropriate predetermined for- 
mats. The traffic broadcast system 20 also includes suit- 
able equipment and programming 20(3) for broadcast- 
ing the data. The equipment and programming 20(3) in- 
cludes interfaces to transmitters, programming that 
communicates formatted messages at regular intervals 
to the transmitters, and so on. The traffic broadcast sys- 
tem 20 also includes transmission equipment 20(4). 



This equipment 20(4) may comprise one or more FM 
transmitters, including antennas, or other wireless 
transmitters. This equipment 20(4) provides for broad- 
casting the formatted messages as traffic and road con- 
5 dition data 50 throughout the region 1 0. Th broadcast- 
ing equipment 20(4) may be part of the traffic broadcast 
system 20, or alternatively, the broadcast system 20 
may use broadcasting equipment from other types of 
systems, such as cellular or paging systems, FM radio 
w stations, and so on, to broadcast the traffic messages 
50 to the vehicles 11 in the region. (For purposes of this 
disclosure and the appended claims, the broadcasting 
of traffic messages is intended to include any form of 
transmission, including direct wireless transmission.) 
15 [0041] Figure 3 illustrates the data components of one 
of the traffic messages 50. The traffic message 50 can 
include various kinds of information. One useful kind of 
information that the traffic message 50 can include re- 
lates to traffic congestion. When used to provide infor- 
20 mation about traffic congestion, the traffic message 50 
includes data components that identify one or more lo- 
cations along a road that are congested, how bad the 
congestion is, and how far the congestion extends. 
[0042] In the embodiment shown in Figure 3, the traf- 
25 fic message 50 includes the following data components: 
an event description 50(1), a location 50(2), a direction 
50(3), an extent 50(4), a duration 50(5) and advice 50 
(6). In alternative embodiments, the traffic message 50 
may also include components that provide other infor- 
30 matiorv50(n). 

[0043] The event description component 50(1) in- 
cludes data that describe a traffic problem 50(1 )(1) 
along with data that describe a level of severity 50(1 )(2) 
of the traffic problem 50(1 )(1). 
35 [0044] The location component 50(2) includes a ref- 
erence number that identifies the location of the traffic 
problem 50(1 )(1). 

[0045] The direction component 50(3) includes data 
that indicate the direction of traffic affected. 

40 [0046] The extent component 50(4) includes data that 
identify a length of a traffic congestion queue with re- 
spect to the location 50(2). The extent component 50(4) 
implicitly defines another (e.g., a secondary location) 
straddling the traffic condition in terms of the number of 

45 location references in between. 

[0047] The advice component 50(6) provides a rec- 
ommendation for a diversion of route. 
[0048] According to one embodiment, the traffic mes- 
sage 50 conforms to the standard format for ALERT-C 

so messages established in the RDS-TMC system. For ex- 
ample, in the RDS-TMC system, the location 50(2) por- 
tion of the message 50 is included in a RDS-TMC code 
51. The RDS-TMC code 51 includes a location number 
51 (1 ), a location table number 51 (2), a country code 51 

55 (3), and a direction 51 (4). The location number 51 (1 ) is 
a unique number within a r gion to which on location 
tabl (i.e., a database of numbers) corresponds. The lo- 
cation table number 51 (2) is a unique numb r assigned 
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to each separate location table. The country code 51(3) 
is a number that identifies the country in which the loca- 
tion referenced by the location number 51 (1) is locat d. 
The direction 51(4) takes into account factors such as 
bi-directionality and whether or not the segments are ex- 
ternal to the junction. The RDS-TMC code 51 is pub- 
lished in the message 50 in a string as follows: 

ABCCDEEEEE 

where: 

A: Direction of the road segment (^direction 51 
(4)) 

P: Country code (=country code 51 (3)) 

CC: Location database number (=location table 

number 51 (2)) 
D: RDS direction (+,-, P, N) (=direction 51(4)) 
EEEEE: Location code (location number 51 (1 )) 

[0049] Vehicles 11 in the region 10 that have appro- 
priate equipment installed in them can receive these 
traffic messages 50. These messages 50 can be pro- 
vided to the drivers or passengers in these vehicles 11 . 

II. IN-VEHICLE NAVIGATION SYSTEM - OVERVIEW 

[0050] Referring again to Figure 2, the components of 
one of the vehicles 11 of Figure 1 are shown. As men- 
tioned above, the vehicle 11 may be a car or truck. In- 
stalled in the vehicle 11 is a navigation system 110. The 
navigation system 11 0 is a combination of hardware and 
software components. In one embodiment, the naviga- 
tion system 110 includes a processor 112, a drive 114 
connected to the processor 112, and a non-volatile 
memory storage device 116 for storing a navigation ap- 
plication software program 118 and possibly other infor- 
mation. The processor 112 may be of any type used in 
navigation systems, such as 32-bit processors using a 
flat address space, such as a Hitachi SH1, an Intel 
80386, an Intel 960, a Motorola 68020 (or other proces- 
sors having similar or greater addressing space). Proc- 
essor types other than these, as well as processors that 
may be developed in the future, may also be suitable. 
[0051 ] The navigation system 1 1 0 may also include a 
positioning system 124. The positioning system 124 
may utilize G PS-type technology, a dead reckoning- 
type system, or combinations of these, or other systems, 
all of which are known in the art. The positioning system 
124 may include suitable sensing devices 123 that 
measure the traveling distance speed, direction, and so 
on, of the vehicle. The positioning system 1 24 may also 
include appropriate technology to obtain a GPS signal, 
in a manner which is known in the art. The positioning 
system 124 outputs a signal to the processor 112. The 
signal from th positioning system 1 24 may be used by 
the navigation application softwar 1 1 8 that is run on the 



8 

processor 112 to determine the location, direction, 
sp ed, etc., of the vehicle 11 . 
[0052] Th vehicle 11 includes a traffic message re- 
ceiver 125. The receiver 125 may be an FM receiver 

5 tuned to th appropriate frequency at which the traffic 
broadcast system 20 is using to broadcast the traffic 
messages 50. The receiver 125 receives the traffic mes- 
sages 50 from the traffic broadcast system 20. (In an 
alternative in which the traffic messages are sent by a 

?o direct wireless transmission, such via a cellular wireless 
transmission, the receiver 125 in the vehicle 11 may be 
similar or identical to a cellular telephone.) The receiver 
125 provides an output to the processor 11 2 so that ap- 
propriate programming in the navigation system 11 0 can 

is utilize the data broadcast by the traffic broadcast system 
20 when performing navigation functions, as described 
more fully below. 

[0053] The navigation system 110 also includes a us- 
er interface 131 . The user interface 131 includes appro- 

20 priate equipment that allows the end-user (e.g., the driv- 
er or passengers) to input information into the navigation 
system. This input information may include a request to 
use the navigation features of the navigation system. 
For example, the input information may include a re- 

25 quest for a route to a desired destination. The input in- 
formation may also include requests for other kinds of 
information. The user interface equipment used to input 
information into the navigation system 110 may include 
a keypad, a keyboard, a microphone, etc., as well as 

30 appropriate software, such as a voice recognition pro- 
gram. The user interface 131 also includes suitable 
equipment that provides information back to the end-us- 
er. This equipment may include a display 1 27, speakers 
129, or other means. 

35 [0054] The navigation system 110 uses a map data- 
base 140 stored on a storage medium 132. The storage 
medium 132 is installed in the drive 114 so that the map 
database 140 can be read and used by the navigation 
system. The storage medium 132 may be removable 

6 and replaceable so that a storage medium with an ap- 
propriate map database for the geographic region in 
which the vehicle is traveling can be used. In addition, 
the storage medium 132 may be replaceable so that the 
map database 140 on it can be updated easily. In one 

45 embodiment, the geographic data 140 may be a geo- 
graphic database published by Navigation Technologies 
of Sunnyvale, California. 

[0055] In one embodiment, the storage medium 132 
is a CD-ROM disk. In an alternative embodiment, the 

so storage medium 132 may be a PCMCIA card in which 
case the drive 114 would be substituted with a PCMCIA 
slot. Various other storage media may be used, includ- 
ing fixed or hard disks, DVD disks, or other currently 
available storage media, as well as storage media that 

55 may be developed in the future. The storage medium 
132 and the geographic database 140 do not hav to 
be physically provided at the location of the navigation 
system. In alternative embodiments, th storage medi- 
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urn 132, upon which some or all of the geographic data 
140 are stored, may be located remotely from the rest 
of the navigation system and portions of the geographic 
data provided via a communications link, as needed. 
[0056] In on exemplary typ of system, the naviga- 5 
tion application software program 11 8 is loaded from the 
non-volatile memory 116 into a RAM 120 associated 
with the processor 1 1 2 in order to operate the navigation 
system. The processor 112 also receives input from the 
user interface 131 . The input may include a request for 
navigation information. The navigation system 110 uses 
the map database 140 stored on the storage medium 
132, possibly in conjunction with the outputs from the 
positioning system 124 and the receiver 125, to provide 
various navigation features and functions. The naviga- 
tion application software program 118 may include sep- 
arate applications (or subprograms) that provide these 
various navigation features and functions. These func- 
tions and features may include route calculation 141 
(wherein a route to a destination identified by the end- 
user is determined), route guidance 142 (wherein de- 
tailed directions are provided for reaching a desired des- 
tination), map display 143, and vehicle positioning 144 
(e.g., map matching). Also included in the programming 
11 8 on the navigation system is location referencing pro- 
gramming 145, which is explained in more detail below. 
Other functions and programming 146, in addition to 
these, may be included in the navigation system 110. 
The navigation application program 118 may be written 
in a suitable computer programming language such as 
C, although other programming languages, such as C++ 
or Java, are also suitable. 

[0057] All of the components described above may be 
conventional (or other than conventional) and the man- 
ufacture and use of these components are known to 
those of skill in the art. 

III. THE GEOGRAPHIC MAP DATABASE 

A. Overview. 

[0058] In one present embodiment, the speed and/or 
functionality of a navigation system can be enhanced by 
a combination that includes improvements in the stor- 
age, arrangement, and/or structuring of the geographic 
data used by the system to facilitate the use of the data 
by some of the functions in the navigation application 
program in the systems that use the data. Based upon 
the manner in which the geographic data are stored, ar- 
ranged, and/or structured, functions in the navigation 
application program that access and use the data can 
implement routines that exploit the improvements incor- 
porated into the geographic data. This combination can 
result in overall improved performance by the navigation 
system. 

[0059] The map databas 140 contains information 
about the roadway network in the geographic region. In 
one embodiment, the map database 140 includes node 



data and segment data. These data represent compo- 
nents of the physical road network. Node data represent 
physical locations in the geographic region (such as 
roadway intersections and other positions) and segment 
data represent portions of roadways between the phys- 
ical locations represented by nodes. Each road segment 
in the geographic region is represented by a road seg- 
ment data entity (i.e., a record) in the map database 1 40. 
Each road segment data record in the map database is 
associated with two nodes which represent the coordi- 
nate positions at each end of the road segment repre- 
sented by the road segment data record. The informa- 
tion included in the node and segment data entities is 
explained with reference to Figures 4 and 5. (The terms 
"nodes" and "segments" represent only one terminology 
for describing these physical geographic features and 
other terminology for these features is intended to be 
encompassed within the scope of these concepts.) 
[0060] Figure 4 illustrates a map 21 0 showing a geo- 
graphic region 21 2. The geographic region 21 2 in Figure 
4 may correspond to the geographic region 1 0 in Figures 
1 and 2, or the geographic region 21 2 may have different 
boundaries. In a present embodiment, the region 10 (in 
Figure 1) for which the traffic broadcast system 20 pro- 
vides traffic condition service is encompassed within the 
region 212 (in Figure 4) represented by the geographic 
database 140. 

[0061] In Figure 4, a plurality of locations 214 are 
shown to be located in the geographic region 212. Each 
of the locations 214 represents a place or point in the 
geographic area 212 at which there is located a feature 
about which it is desired to include information in a ge- 
ographic database. Each of these locations 214 has a 
unique physical location (latitude, longitude, and option- 
ally absolute or relative altitude) and each of the loca- 
tions 214 can be uniquely identified by its two dimen- 
sional (or three dimensional) geographic coordinates (i. 
e., latitude, longitude, and optionally altitude). A location 
21 4 may correspond to an intersection at which two or 
more roads meet, a point along a road segment at which 
the direction of the road changes, a point along a road 
segment at which the speed limit changes, a point at 
which a road reaches a dead end, and so on. The loca- 
tion 214 may correspond to a position of a point-of-in- 
terest, such as a hotel or civic center, a boundary of a 
natural feature, such as a lake, or a position along a rail- 
road track or ferry. Each of the locations 214 may cor- 
respond to anything physically located in the geographic 
area 212. 

[0062] Figure 5 shows an expanded view of a portion 
216 of the map 210. The portion 216 in Figure 5 illus- 
trates part of the road network 220 in the geographic 
region 212. This road network 220 may correspond to 
the road network 12 in Figures 1 and 2 or alternatively 
the road networks 220 and 12 may be different. In a 
present mbodiment, the road network 12 about which 
the traffic broadcast system 20 provides traffic condition 
data is encompassed within the road network 220 rep* 
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resented by the geographic database 1 40. The road net- 
work 220 includes among other things, roads and inter- 
s cttons located in the geographic region 21 2. As shown 
in Figure 5, in the illustrated portion 21 6 of the map 21 0, 
each road in the geographic region 21 2 is composed of 5 
one or more segments, 222(1), 222(2)... 222(n). In one 
embodiment, a road segment represents a portion of the 
road. In Figure 5, each road segment 222 is shown to 
have associated with it two nodes 223: one node repre- 
sents the point at one end of the road segment and the 
other node represents the point at the other end of the 
road segment. The node at either end of a road segment 
may correspond to a location at which the road meets 
another road, e.g., an intersection, or where the road 
dead ends, 

[0063] In one type of geographic database, there is at 
least one database entry (also referred to as "entity" or 
"record") for each road segment represented in a geo- 
graphic region. This road segment data record may 
have associated with it information (such as "attributes", 
"fields", etc.) that allows identification of the nodes as- 
sociated with the road segment and/or the geographic 
positions (e.g., the latitude and longitude coordinates) 
of the two nodes. In addition, the road segment record 
may have associated with it information (e.g., more "at- 
tributes", "fields", etc.), that specify the speed of travel 
on the portion of the roadway represented by the road 
segment record, the direction of travel permitted on the 
road portion represented by the road segment record, 
what if any turn restrictions exist at each of the nodes 
which correspond to intersections at the ends of the road 
portion represented by the road segment record, the 
street address ranges of the roadway portion represent- 
ed by the road segment record, the name of the road, 
and so on. Each segment data entity that represents an 
other-than-straight road segment may include one or 
more shape point data attributes that define the other- 
than-straight shape of the road segment. The various 
attributes associated with a road segment may be in- 
cluded in a single road segment record, or preferably 
are included in more than one type of road segment 
record which are cross-referenced to each other. 
[0064] In a geographic database that represents the 
region 212, there may also be a database entry (entity 
or record) for each node in the geographic region. The 
node data record may have associated with it informa- 
tion (such as "attributes", "fields", etc.) that allows iden- 
tification of the road segment(s) that connect to it and/ 
or its geographic position (e.g., its latitude and longitude 
coordinates). 

B. Separate subsets of geographic data 

[0065] Referring to Figure 6, there is a diagram illus- 
trating the organization of the geographic database 1 40 
by data type. One way that the accessing of geographic 
data can be enhanced for performing various navigation 
functions is to provide separate collections or subsets 



of th g ographic data 140 for use by each of the sep- 
arate functions ( .g., 141-146) in the navigation appli- 
cation program 118. Each of th se separate subsets is 
tailored specifically for us by one of the functions. For 
instance, the route calculation function 141 (in Figure 2) 
normally requires only a portion of all the information in 
the geographic database that is associated with a seg- 
ment of a road. When the route calculation function 141 
is being run, it may require information such as the 
speed along a road segment, turn restrictions from one 
road segment to another, and so on. However, the route 
calculation function 141 does not necessarily require the 
name of the road to calculate a route. Similarly, when 
using the map display function 143, some of the infor- 
mation associated with a road segment, such as the 
speed limits or turn restrictions, is not required. Instead, 
when the map display function 143 is run, it uses only a 
portion of the information associated with the road seg- 
ment, such as the shapes and locations of roads, and 
possibly the names of the roads. Even further, when the 
route guidance function 142 is being run, some of the 
information associated with a segment of a road, such 
as the speed and turn restrictions, is not required. In- 
stead, when the route guidance function 142 is being 
run, it uses information that includes the name of the 
road represented by the road segment, the address 
range along the road segment, any signs along the road 
segment, and so on. Although there may be some over- 
lap as to the types of information used by the various 
navigation functions, some of the data used by any one 
of these navigation functions is not used by another of 
the functions. If all the information relating to each road 
segment were associated with it as a single data entry 
in a single database, each data entity record would be 
relatively large. Thus, whenever any one of the naviga- 
tion functions accessed an entity record, it would have 
to read into memory a significant amount of information 
much of which would not be needed by the navigation 
function. Moreover, when reading the data entity from 
disk, relatively few data entities could be read at a time 
since each data entity would be relatively large. 
[0066] In order to provide the information in the geo- 
graphic database in a format more efficient for use by 
each of the navigation functions, separate subsets of the 
entire geographic database for a given geographic re- 
gion are provided for each of the different types of nav- 
igation functions to be provided in the navigation appli- 
cation program 118. 

[0067] Figure 6 illustrates the geographic database 
140 comprised of separate routing data 236, carto- 
graphic data 237 (for map display), maneuver data 238 
(for route guidance), point-of-interestdata 239 (for iden- 
tifying specific points of interest, such as hotels, restau- 
rants, museums, stadiums, airports, etc.), and junction 
data 240 (for identifying named intersections). In addi- 
tion to thes types of data, the geographic database 1 40 
may include navigation feature data 241 . This subset of 
data includes th names of the navigable features (such 
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as roads). Th geographic database may also include 
data subsets for postal codes 243 and places 244 (e.g., 
cities, stat s, and counties). In a present embodim nt, 
the geographic database 140 includes a separate sub- 
set of data for location references 245, as explained fur- 
ther below. A geographic database may be defined with 
fewer or more subsets than these, and other types of 
data 246 may be defined and included. 
[0068] Each subset of data includes only the data re- 
quired to be used by a particular navigation function. 
There is some overlap of data between each of these 
subsets, with the result that some parts of the informa- 
tion may be included in more than one subset. For ex- 
ample, both the road segment data entity in the routing 
data subset 236 as well as the road segment data entity 
in the cartographic data subset 237 may include at- 
tributes identifying the nodes located at the ends of the 
segments. Although this duplication may result in a larg- 
er overall data storage requirement, each of the naviga- 
tion functions benefits from the resultant efficiency of 
handling smaller amounts of data. 
[0069] Providing for separate subsets of geographic 
data for each of the navigation functions also takes into 
account that usage of each of these navigation functions 
relates to the others of the navigating functions in ex- 
pected ways. For example, an end-user may first want 
to view a present position, then enter a destination, then 
receive instructions how to start toward the destination, 
then observe a map showing the initial portion of the 
route, then receive further instructions, then have a map 
displayed of the next portion of the route, and so on. 
Because of this type of expected usage, dividing the da- 
ta into subsets provides for efficient use of the data when 
using each separate function. 
[0070] Although the division of the geographic data in- 
to subsets provides for efficient use of the data by each 
of the different navigation functions, it becomes neces- 
sary to provide that the different navigating functions 
that use these different subsets of the database work 
together. For example, in the example mentioned 
above, after an end-user obtains a calculated route, it 
may be desired to display a map on a computer display 
with the calculated route highlighted. In order to accom- 
plish this, the routing subset 236 of geographic data is 
accessed first to obtain the routing road segment data 
entities for the optimum route, and then the cartographic 
subset 237 of the geographic database is accessed to 
obtain the cartographic road segment data entities cor- 
responding to the routing data entities. To permit these 
data subsets to work together, indices may be included 
that provide cross references, search trees, or other da- 
ta finding techniques. Indices can be located within any 
of the subsets of data or external of any of the subsets. 
In Figure 6, external indices 247 are shown. Storing in- 
dices external of the data that are being indexed has th 
advantage that the index can be loaded and used to de- 
termine which data among the various subsets of data 
needs to be loaded next. 



C. Layering of geographic data 

[0071] Another way that the geographic data can be 
organiz d to nhance their use is to provide the data in 

5 layers. Some of the navigation functions (such as the 
map display function 143 and the route calculation func- 
tion 141 in Figure 2) may use data at different levels of 
detail. For example, when using the map display func- 
tion 143, it is sometimes desired to provide for panning 

10 and zooming. Zooming can be done more efficiently if 
the data are organized into layers, with greater detail at 
the lower layers and less detail at the higher layers. 
When using the route calculation function 141 , it is also 
advantageous to use the data at different levels of detail. 

15 For example, when calculating a route between two lo- 
cations, it would be inefficient to examine all the possible 
road segments that diverge from each intersection 
along the route, including secondary streets and alleys. 
Instead, once a route is "on" a main road or expressway, 

20 it is generally preferable to stay on main roads or ex- 
pressways until it is necessary to exit to secondary 
roads as the destination is approached. If the routing 
data are layered, higher layers that omit secondary 
roads can be used when possible to minimize the pos- 

25 sible road segments to be investigated when calculating 
the route. Therefore, within some of the subsets of data 
types, the geographic data are provided in separate col- 
lections or groups corresponding to separate layers. 
[0072] To implement layering, each road segment da- 

30 ta record in the map database 140 also identifies the 
rank of the corresponding portion of the roadway that it 
represents. A rank of a road segment may correspond 
to its functional class. Road segments having a rank of 
"4" may include high volume, controlled access roads, 

35 such as expressways and freeways. Road segments 
having a rank of "3" may be high volume roads with few 
speed changes, but are not necessarily controlled ac- 
cess roads. The lower ranked roads handle correspond- 
ing lower volumes and generally have more speed 

40 changes or slower speeds. Roads having a rank of H 0" 
can handle the lowest volumes. For example, these 
roads lowest ranked roads may include side streets, al- 
leyways, etc. 

[0073] The rank of a road segment data entity also 
<5 specifies the highest data layer in which a road segment 
entity is included. For example, referring to Figure 7, the 
routing type data 236 may include five separate layers 
of the data, RO, R1 , R2, R3, and R4, each comprising 
a separate collection of the routing data with a different 
so level of detail, which can be used by the route calculation 
function. In the routing data type of the geographic da- 
tabase, layer 0 ( n R0 M ) includes the road segment data 
entities (and some or all of their corresponding routing 
data attributes) having a rank of "O" or higher. Thus, layer 
55 o includes road segm ntdata ntiti s corresponding to 
all the portions of all the roads in the geographic r gion. 
Layer 1 of the routing data 236 comprises a separat 
subset (or collection) of th routing data and includes 
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only the routing segment data entities (and some or all 
of their corresponding routing data attributes) having a 
rank of "1" or higher. Layer 2 of the routing data com- 
prises a separate subset of the routing data and includes 
only the routing segment data entities (and some or all 
of their corresponding navigation data attributes) having 
a rank of level 2 or higher, and so on. A highest layer 
(layer n) includes only records having a rank of n. In a 
present embodiment, n is equal to 4, although in other 
embodiments, n may be any number greater than 0. 
Each higher layer includes fewer records, however 
these records represent roads upon which travel is gen- 
erally faster. 

[0074] Similarly, the other types of data, such as the 
cartographic subset type 237 may include separate col- 
lections of the data, each with a different level of detail, 
which can be used by the map display function. Using 
these different layers of cartographic data, the map dis- 
play function can provide rapid panning and zooming. 
[0075] Although the organization of some of the data 
into layers results in some duplication of the data, the 
increased efficiency provided by layering generally off- 
sets any disadvantages. As with the use of separate 
types of data mentioned above, the need arises to allow 
these layers to work together. Indices 249 may be pro- 
vided for this purpose. In Figure 7, internal indices are 
shown. Internal indices 249 are included among the var- 
ious types of data. 

D. Parcelization of geographic data 

[0076] Figure 8 is a diagram illustrating the organiza- 
tion of the geographic database 140 embodied on the 
data storage medium 132. The geographic database 
1 40 on the medium 1 32 includes header and global data 
321 and geographic data 310. The header and global 
data 321 include information pertaining to the entire ge- 
ographic database 140, such as an identification of the 
region (e.g., 212 in Figure 4) represented by the data- 
base, the release date of the database, what kinds of 
data compression are used, if any, and so on. The ge- 
ographic data 310 includes the data relating to the ge- 
ographic features. Specifically, the geographic data 310 
includes all the data which correspond to the different 
types of geographic data represented in Figure 6, such 
as the routing data 236, the cartographic data 237, the 
maneuver data 238 and so on. The geographic data 31 0 
also include indices, such as the indices 247 shown in 
Figure 6 and the indices 249 shown in Figure 7. 
[0077] Within the geographic database 1 40, the geo- 
graphic data 31 0 are organized by type (shown in Figure 
6) and by layer (as shown in Figure 7) for those types 
that have layers. Within each type and layer, the data 
310 are comprised of a plurality of data entities or 
records. Within each type and layer, these data entities 
are grouped into a plurality of parcels 320. Each parcel 
contains a portion of the plurality of data entities which 
comprise each type or layer of the geographic data 31 0. 



In on embodiment, the size of each parcel conforms to 
a regular data size, .g., sixteen kilobytes, ight kilo- 
bytes, etc. This organization of data records into pare Is 
facilitates storag and retrieval of the geographic data. 

5 In one embodiment, all the data which correspond to the 
different types of geographic data represented in Figure 
6, such as the routing data 236, the cartographic data 
237, the maneuver data 238, and so on, are organized 
into parcels 320. 

10 [0078] Methods for parcelizing data are disclosed in 
copending applications Sen Nos. 08/740,295 and 
08/924,328 (Atty Docket No. 7117-61 filed September 
5, 1997), the disclosures of which are incorporated by 
reference herein. 
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IV. COORDINATION OF TRAFFIC MESSAGES WITH 
GEOGRAPHIC MAP DATABASE 



A. Overview. 



20 



[0079] In a present embodiment, a means is provided 
that facilitates using traffic messages that are broadcast 
by a traffic broadcast system in conjunction with a nav- 
igation system that also uses a geographic database. 
25 For example, with reference to the traffic message sys- 
tem 20 shown in Figures 1 and 2, the present embodi- 
ment provides a means that facilitates using the traffic 
messages 50 broadcast by the broadcast system 20 in 
conjunction with the navigation system 1 1 0 that uses the 
30 geographic database 1 32 shown in Figures 1 , 2 and 6-8. 
Using broadcast traffic messages together with a geo- 
graphic database allows a navigation system to provide 
improved navigating features to a driver. In addition, us- 
ing broadcast traffic messages together with a geo- 
35 graphic database also allows a navigation system to 
provide navigation features that had previously been un- 
available. One important advantage of using traffic 
broadcast messages together with a geographic data- 
base is that a route calculation function in the navigation 
40 system can take into account up-to-the-minute traffic 
conditions when calculating a route to a desired desti- 
nation location. 

[0080] In order to use traffic messages together with 
a geographic database, the present embodiment pro- 
45 vides a means by which the navigation system relates 
the data in the traffic messages to the data in the geo- 
graphic database. One consideration in this process is 
that the data in the traffic message may have a different 
form than the data in the geographic database. Another 
so consideration is that the traffic broadcast system may 
assign specific reference codes to locations in the geo- 
graphic region about which the traffic messages relate. 
Traffic broadcast systems, such as the RDS-TMC sys- 
tem, use these reference codes instead of the actual lo- 
ss cation names for several r asons. For example, using 
reference codes avoids possible ambiguities that might 
arise if actual street names or addresses were used. Al- 
so, specially assigned codes may be necessary wher 
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particular locations along roads do not have names. In 
addition, using codes instead of actual location names 
may reduce the ov rail size of the data messages that 
are broadcast. 

[0081 ] Although using reference codes for identifying 
particular locations may be helpful for traffic broadcast 
systems that provide information about traffic conges- 
tion, and in particular about congestion along major 
highways, such location reference codes may not be 
readily usable by navigation systems that include geo- 
graphic databases. One reason that navigation systems 
may not be able to readily use the location reference 
codes assigned by the traffic broadcast system is that 
these codes do not necessarily correspond to any 
known physical features. For example, the location ref- 
erence codes for positions along an interstate highway 
may be arbitrary n-bit (e.g., 20 bit) numbers. These num- 
bers by themselves do not necessarily have any mean- 
ing for end-users of navigation systems, such as motor- 
ists. Motorists are not likely to know the n-bit location 
reference code number for a particular highway inter- 
change. Likewise, a traffic message that identified a lo- 
cation of traffic congestion by referring to its n-bit loca- 
tion reference number would not necessarily have any 
meaningful significance to end-user drivers. 
[0082] As noted above, one example of a traffic 
broadcast system is the RDS/TMC system. The RDS- 
TMC messages conform to the ALERT-C protocol. In 
the RDS/TMC system, many primary and some second- 
ary road interchanges have predefined location num- 
bers. These location numbers are a part of the traffic 
messages that are broadcast. These location numbers 
are assigned by the road authorities or other parties in- 
volved in the development and maintenance of the RDS/ 
TMC system. These location numbers are standardized 
for all users. That is, any receiver that uses the messag- 
es from the traffic broadcast system is required to be 
able to relate the location reference numbers in the 
RDS-TMC messages to the known locations to which 
the numbers are assigned. 

[0083] In places where these types of location num- 
bers are assigned, the location reference numbers may 
be unique within a regional database of the specific traf- 
fic broadcast system. Such a regional database is 
known as a "location table." A separate location table is 
defined for each different region. This location table re- 
gion corresponds to the region 10 in Figure 1, but does 
not necessarily correspond to (i.e. , have boundaries that 
coincide exactly with) the geographic area 21 2 in Figure 
4. 

[0084] Figure 9 shows one example of how location 
reference numbers are assigned. The example of Fig- 
ure 9 is similar to the RDS/TMC system. Figure 9 illus- 
trates a portion of a roadway 500. This roadway 500 is 
one of the roadways in the roadway network 12 (in Fig- 
ure 1 ) about which the traffic broadcast syst m 20 mon- 
itors traffic congestion and about which the traffic broad- 
cast system 20 reports on traffic congestion by means 



of traffic messages 50. 

[0085] In order to identify locations along the roadway 
500 at which traffic congestion occurs, location r fer- 
ence numbers ( .g., LR12005, LR12006, and LR13297) 

5 are pr assigned to locations along th roadway 500. 
These location reference numbers are assigned by the 
road authorities or others involved with the traffic broad- 
cast system 20. The messages 50 (in Figures 1-3) 
broadcast by the traffic broadcast system 20 include 

10 these location reference numbers when identifying lo- 
cations of traffic congestion. 

[0086] In traffic broadcast systems, such as the RDS- 
TMC system, the roadway 500 being monitored and 
about which traffic messages are broadcast is usually 

is an expressway or major arterial road. Traffic conditions 
along minor roads may not be monitored by these kinds 
of traffic broadcast systems. Accordingly, in traffic 
broadcast systems, such as the RDS-TMC system, lo- 
cation reference numbers are assigned to locations 

20 along expressways and major arterial roads, but not 
along minor roads. 

[0087] Figure 9 shows only three location numbers, 
LR12005, LR12006, and LR13297. It is understood that 
in a typical traffic broadcast system, there may be hun- 

25 dreds, thousands, or more, of location reference num- 
bers assigned to locations along roads in each region 
represented by a location table. As shown in Figure 9, 
the location reference numbers correspond to inter- 
changes along the roadway 500. However, location ref- 

30 erence numbers may be assigned to any position along 
the roadway 500, including positions between inter- 
changes. 

[0088] In traffic broadcast systems, such the RDS- 
TMC system, directions may be defined as positive or 

35 negative. For example, in the RDS-TMC system, the di- 
rection is positive for travel directions west to east and 
from south to north. The location reference numbers 
may be, but are not necessarily, assigned in consecutive 
order along a roadway. 

40 [0089] In traffic broadcast systems, such a the RDS- 
TMC system, each roadway is assigned its own location 
reference numbers. The location reference numbers of 
one roadway are not shared with other roadways. 
Therefore, at an interchange between two roadways 

45 each of which is assigned location reference numbers, 
one location reference number is assigned to the inter- 
change for the first of the roadways and a second dif- 
ferent location reference number is assigned to the 
same interchange for the second of the roadways. Thus, 

so a single interchange may have two or more location ref- 
erence numbers assigned to it, one for each of the road- 
ways that meet at the interchange. 
[0090] As mentioned above, one of the difficulties as- 
sociated with using the location reference numbers with 

55 a navigation syst m that uses a geographic database is 
that the location ref rence numbers do not necessarily 
relat to any physical roadway features. As illustrated 
in Figur 9, the roadway 500 is shown to consist of in- 
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dividual road segments, labeled S101, S102, ... S132. 
These road segments S1 01 , S102, ... S132, correspond 
to individual portions (i.e., segments) of the roadway 
500. For example, each of these individual segments of 
the roadway 500 may comprise a portion of the roadway 
500 between intersections of the roadway 500 with other 
roads, including on-ramps and off-ramps. In the geo- 
graphic database 140 (in Figure 2), each of these sep- 
arate road segments, S101, S102, ... S132, is repre- 
sented by at least one separate data record. 
[0091] In the roadway 500 shown in Figure 9, there 
are separate road segments associated with the lanes 
of the roadway 500 for each direction. This represents 
a typical expressway configuration in which the lanes 
going in one direction are physically separate from the 
lanes going in the other direction. Where the lanes are 
actually physically separate from each other, such as in 
the portion of the roadway 500 depicted in Figure 9, 
there may be separate segment data records in the ge- 
ographic database 1 40 for the lanes in one direction and 
the lanes in the other direction. Even where the lanes of 
the roadway are not physically separated from each oth- 
er, they may be represented by separate data records 
in the geographic database. Alternatively, a single seg- 
ment data record may be included in the database that 
represents all the lanes of the roadway in both direc- 
tions. The database records include attributes that indi- 
cate whether they represent lanes in both directions or 
only lanes in a single direction. 
[0092] As illustrated in Figure 9, there may be multiple 
segments, S101, S102, ... S132, of the roadway 500 as- 
sociated with each location along the roadway 500 to 
which a location reference number (e.g., LR12005, 
LR1 2006 . . ) has been assigned. As stated above, each 
of these multiple segments of the roadway 500 may be 
represented by at least one record in the geographic da- 
tabase 140. Moreover, as illustrated by Figure 9, there 
may also be several segments of the roadway 500 lo- 
cated between the interchanges along the roadway 500 
to which location reference numbers have been as- 
signed. Each of these segments of the roadway 500 be- 
tween interchanges may be represented by at least one 
record in the geographic database 140. However, none 

of these individual road segments S101, S102 , 

S132, is separately identified as relating to the location 
reference numbers by the traffic broadcast system in the 
messages that are broadcast. 

[0093] As mentioned above, it would be advanta- 
geous if the data in the traffic messages 50 could be 
utilized when calculating a route using the route calcu- 
lation function 141 in the navigation system 110 (in Fig- 
ure 2). If the data in the traffic messages could be used 
by the navigation system, the segments associated with 
traffic congested locations that are assigned location 
reference numbers could be avoided by the route cal- 
culation function. Unfortunately, as exemplified by Fig- 
ure 9, the location numbers assigned by the traffic 
broadcast system authorities do not directly relate to any 



physical feature represented by the data records in the 
geographic databas 1 40. Moreover, the traffic m ssag- 
es broadcast by the traffic broadcast system 20 do not 
necessarily relat to any of th actual road s gments 
s that are repres nted by data records in the geographic 
database. 

[0094] Still another factor that complicates using the 
traffic messages broadcast by a traffic broadcast system 
in a route calculation function in a navigation system is 

10 that, in systems such as the RDS-TMC system, the 
length of the roadway affected by an occurrence of traf- 
fic congestion is reported in terms of the "extent" data 
50(4) which is included in the broadcast traffic message, 
as mentioned above in connection with Figure 3. The 

15 "extent" data are defined in terms of the number of ad- 
jacent positions represented by location numbers that 
are affected by the traffic congestion condition relative 
to the position along the roadway identified by the loca- 
tion reference number in the traffic message. Thus, the 

20 "extent" data 50(4) also do not bear any direct relation- 
ship with physical features represented by data records 
in the geographic database. Using "extent" data in traffic 
messages compounds the difficulty of incorporating traf- 
fic broadcast message information in the route calcula- 

25 tion function 141 of the navigation system 110. 

[0095] In order to use the traffic message data to sup- 
port a route calculation function, a way is required that 
relates the location reference data from a traffic mes- 
sage to the geographic data (such as the segment data 

30 records) in the geographic database used by the route 
calculation function. In a route calculation function, such 
as the function 141 shown in Figure 2, route calculation 
may be performed by exploring multiple potential solu- 
tion routes from a starting location to a destination loca- 
ls tion. The route calculation function 1 41 may perform this 
process by comparing multiple possible paths from in- 
tersections along parts of potential solution routes and 
selecting the path that has the best overall cost, based 
upon some cost assignment criteria. To compare these 

40 potential solution routes, or parts thereof, the data 
records that represent each road segment in these po- 
tential solution routes are examined. These data 
records include information from which a comparison of 
the potential solution routes can be made. For example, 

45 the data records that represent road segments may in- 
clude attributes that indicate the speed limit along the 
represented road segment, whether there is a stop light 
at the end of the road segment, and so on. Using these 
data, the potential solution routes can compared to each 

so other so that the best solution route (e.g. , the route with 
the fastest overall travel time or the least overall dis- 
tance) can be selected. 

[0096] It can be appreciated that the data in the traffic 
messages 50 broadcast by the traffic broadcast system, 
55 such as the data that identify areas of traffic congestion, 
may b pertinent to the calculation of th best overall 
rout . In order to incorporate the information in the traffic 
data messages into the route calculation function, it is 
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required to identify the data records that r present th 
road segments that are associated with the interchang- 
s, including those road segments that lead into th in- 
terchanges, for which location reference numbers have 
been assigned by the traffic broadcast system 20. s 
[0097] To provide this function, present embodiments 
include combinations of features and/or components 
that allow a navigation application program 118 in the 
navigation system 1 1 0 to use the data in the traffic mes- 
sages 50. According to one aspect of a present embod- f o 
iment, location reference data records are formed, 
stored and used to identify certain segment data records 
in the geographic database as being associated with 
certain location reference numbers. These location ref- 
erence records may be included in the geographic da- is 
tabase 1 41 or may be provided to vehicles via a wireless 
communication link. The components of a location ref- 
erence record are illustrated in Figure 11. According to 
another aspect of a present embodiment, one or more 
indices are formed, stored and used to relate location 20 
reference numbers to location reference records. These 
indices are illustrated in Figure 1 3. According to another 
aspect of a present embodiment, parcels of location ref- 
erence data record are formed, stored, and used. A par- 
cel containing location reference data is illustrated in 25 
Figure 1 2. According to another aspect of a present em- 
bodiment, data are formed, stored and used to identify, 
for each location reference number, the immediately 
previous and the immediately next location reference 
number. This allows the "extent" data in a broadcast 30 
message to be interpreted and related to records in the 
geographic database. According to still another aspect 
of a present embodiment, programming is included in 
the navigation system that queries the geographic da- 
tabase and returns the data entities associated with cer- 35 
tain identified location reference numbers. This aspect 
of the present embodiment is illustrated in Figures 14 - 
16. 

[0098] Each of these aspects is described below. 

40 

B. Location Keys. 

[0099] As part of a present embodiment, data records 
are formed that provide for the association of certain da- 
ta entities in the geographic database used by the nav- 45 
igation system with the location reference codes used 
by the traffic broadcast system. In a present embodi- 
ment, a "location key" is formed as part of this process. 
The location key is an aggregation of data components 
that relate to a location reference code. Each location so 
key forms a unique identifier for that location code in the 
geographic database. Because of this feature, the loca- 
tion keys can be used as entity ID'S for these records in 
the geographic database. 

[0100] The components of a location key 505 ar ss 
shown in Figure 10. The location key 505 is formed of 
a combination of the country code, the location tabl 
number and the location number. This combination to- 



gether forms a unique 32 bit number. The location 
number is 16 bits, the location table number is 6 bits, 
and the country code is 4 bits. This unique number is 
used as a numeric sort key, as explained below. 

C. Data components of location records. 

[01 01 ] After the location keys are formed to provide a 
unique identifier for each location in the region repre- 
sented by the geographic database for which one or 
more traffic broadcast systems have assigned location 
reference numbers, the data entities in the geographic 
database to be associated with each location key are 
identified. In a present embodiment, the data entities 
that represent road segments that are contained in or 
that lead into the interchanges represented by location 
keys are identified. For example, referring to Figure 9, 
the interchange associated with the location reference 
number LR12006 contains both internal segments and 
external segments. The internal segments of the inter- 
change represented by the location reference number 
LR12006 include S113 and S114. The external seg- 
ments of the interchange represented by the location 
reference number LR12006 include the two segments, 
S11 0 and S11 2, that lead into the interchange in the pos- 
itive direction and the two segments, S122 and S123, 
that lead into the interchange in the negative direction. 
The segment data entities associated with these 6 seg- 
ments (S113, S114, S110, S112, S122 and S123) are 
identified as being associated with the location key for 
the interchange LR 12006. 

[0102] The segments leading out of the interchange 
LR12006, such as S121 and S111, are not associated 
with the location reference number for the interchange. 
Instead, these segments are associated with the loca- 
tion reference number of the interchange that they lead 
into. In the illustration of Figure 9, the segment identified 
by S121 leads into the interchange represented by the 
location reference number LR13297, and the segment 
identified by S111 leads into the interchange represent- 
ed by the location reference number LR 12005. Accord- 
ingly, they are associated in the geographic database 
with the location keys for those interchanges. 
[0103] Figure 11 illustrates a location reference data 
record 260. The entity ID for this record is the location 
key, formed in the manner described above. The loca- 
tion reference record 260 includes a list 260(1) of seg- 
ment ID'S, (e.g., segment ID(x), segment ID(w), seg- 
ment ID(p)... segment ID(j)). These segment ID's iden- 
tify the segment data records that represent the road 
segments associated with the interchange identified by 
the location reference key. In the case of the location 
reference record that represents the interchange 
LR12006 in Figure 9, there would be 6 segment ID's in 
the list 260(1) of entity ID's, i.e., S113, S114, S110, 
S112,S122, andS123. 

[0104] In the list 260(1 ), the segment ID's are ordered. 
Various orderings may be used. In a present mbodi- 
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ment, the segment ID'S are ordered to provide a valid 
navigable path. For example, S123, S122, S113, would 
form a valid path in the negative ( M N") direction and 
S110, S112, and S114 form a valid path in the positive 
( U P M ) direction. 

[01 05] As mentioned above in connection with Figure 
7, the geographic database 140 may Include more than 
one layer of certain types of data, such as the routing 
data 236. Each of these layers may assign a different 
segment ID to the same road segment. This has the re- 
sult that the same road segment may be represented by 
more than one segment ID in the geographic database. 
The iist 260(1 ) of segment entity ID'S in the location ref- 
erence data record 260 may include the segment record 
ID's for the lowest layer (i.e., layer R0), or for any other 
layer (e.g., layers R1-R4). Alternatively, the list 260(1) 
may include the segment entity ID's for more than one 
layer or for all the layers. If the list 260(1) of segment 
entity ID's includes the segment record ID's for the low- 
est layer only, a means may be provided to obtain the 
corresponding segment ID's of the road segments in 
other layers. For example, the segment data records in 
layer 0 may include references to the corresponding 
segment data records in other layers that represent the 
same road segment. 

[01 06] Because the roadways to which location refer- 
ence numbers have been assigned by the traffic broad- 
cast system tend generally to be high volume, limited 
access roads, the roadway tends to be made up of seg- 
ments of only the highest rank, e.g., rank 4. 
[0107] When a geographic database 140 includes 
layers, higher layers may include data records that rep- 
resent aggregations of individual road segments. Ag- 
gregations of road segments in higher layers may be 
represented by separate data records because the in- 
tersections of the higher ranked road segments with 
lower ranked road segments may be suppressed or 
eliminated in the higher layers in which the lower ranked 
roads are not included. Using aggregated segments da- 
ta records may enhance performance of some naviga- 
tion functions. When these aggregated segments data 
records represent portions of roads that are associated 
with location reference numbers and the list 260(1) of 
segment ID's in a location reference record 260 includes 
only layer 0 segment ID's, the layer 0 segment data 
records that represent road segments that are included 
in aggregations of road segments that are represented 
in higher layers by aggregated segments data records 
may include references that identify the associated ag- 
gregated segments data records. Alternatively, the seg- 
ment ID's of aggregated segments data records may be 
included in the list 260(1) of the location reference 
record. 

[0108] In addition to the list of segment ID's associat- 
ed with ach location reference number, the location ref- 
erence r cord 260 may identify other data entities 260 
(2) associated with the location represented by th lo- 
cation reference number. For example, the location ref- 



erenc record 260 may include a list of nod ID's that 
represent th nodes associated with the location refer- 
ence number. 

[0109] The location reference number data record 
5 260 may also include other data components. For ex- 
ample, th location reference number 260 includes a di- 
rection attribute 260(3). The location reference number 
260 may also optionally include an intersection attribute 
260(4). The direction attribute 260(3) indicates the di- 
10 rection of the location reference number. The intersec- 
tion attribute 260(4), if provided, includes data that indi- 
cates the type of location represented by the location 
reference record. For example, the intersection attribute 
260(4) may include data that indicates that the location 
15 identified by the location reference number is a ramped 
interchange, a terminus, or that the intersection includes 
stoplights, and so on. The location reference number 
data record 260 may also include other data 260(5). 

20 D. Location reference record organization in the 
database. 

[0110] The data components of all the location 
records, such as the record shown in Figure 11, are or- 

25 ganized, arranged and stored in the geographic data- 
base 140 used by the navigation system in a manner 
that facilitates the rapid identification and retrieval of all 
associated segment records, given a location reference 
number and an extent. The organization, arrangement 

30 and storage of the location reference data are illustrated 
in connection with Figures 12 and 13. 
[0111] As a preliminary step to locating the segment 
records in the geographic database which are associat- 
ed with a location reference number, the location key 

35 505 associated with the location reference number is 
used. As mentioned above, the location key is formed 
of the components of a traffic message that includes a 
location reference number. Then, in order to find the da- 
ta records associated with each location reference key, 

40 a location key index 247(LR) is used. The location key 
index 247(LR) is formed and stored in or with the geo- 
graphic database 140. This location key index 247(LR) 
may be located in a portion of the geographic database 
140 separate from the location reference record data 

45 245. Referring to Figure 13, in a present embodiment, 
the location key index 247(LR) is included among the 
index files 247 (also shown in Figure 6). By storing the 
location key index 247(LR) separately from the location 
reference record data 245, the entire location key index 

so 247(LR) may be read into the memory of the navigation 
system and used to identify the location of the desired 
location reference record. Storing the location key index 
247(LR) separately from the location reference data 
avoids the need to load unnecessary data into the mem- 

55 ory of the navigation system thereby enhancing per- 
formanc . D pending upon th memory resources of 
the navigation syst m, the location key ind x 247(LR) 
may b maintained in memory along with other indices 
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included among the index files 247. Alternatively, the lo- 
cation key index 247(LR) may be loaded into memory 
and used only when needed. (If the size of the location 
key index 247(LR) is relativ ly larg , it may be required 
to store it in more than one parcel.) 
[0112] In the embodiment shown in Figure 13, the lo- 
cation key index 247(LR) does not identify the location 
of each specific location reference record, but instead 
the location key index 247(LR) identifies the parcel 320 
(LR) of location reference data 245 that contains that 
desired location reference record. As shown in Figure 
13, the location key reference index 247(LR) includes a 
list 51 0 of entries. The entries in this list 51 0 include only 
those location reference keys 505 that correspond to the 
first location reference records In each of the plurality of 
parcels 320(LR) that contain location reference data 
245. Each of the entries in the list 510 also includes an 
identification of the parcel of data that includes the lo- 
cation reference record that corresponds to the location 
key in the entry. This identification may be a pointer or 
other reference, or alternatively, the identification may 
be a parcel ID from which the location of the parcel in 
the database and/or on the medium can be determined. 
[0113] The location reference keys 50 in the list 510 
in the location key index 247(LR) are sorted and/or ar- 
ranged in order (e.g., numerically smallest to largest, or 
vice versa). Therefore, the entries in the list 510 can be 
used to identify the parcel in which the location refer- 
ence record associated with any location key is located. 
Given a location key, the list 510 can be traversed until 
an entry larger than the given location key is encoun- 
tered. Then, the parcel that contains the location refer- 
ence record associated with the given location key is the 
parcel referenced by the previous entry in the list. Alter- 
natively, other searching techniques (e.g., binary 
searches) can be used to find the parcel that contains 
a desired location reference number. Thus, this list 510 
accommodates searching techniques that allow finding 
the parcel that contains a location reference record 
quickly. 

[01 1 4] If the list 51 0 of entries in the location key index 
247 would comprise more than one parcel, then a 
search tree may be constructed above this list to facili- 
tate searching for the location key parcel by key. Thus, 
the location key index may comprise a multiple layer 
search tree, each layer of which may be binary searched 
by key for a location tree parcel at the next lower layer, 
or (from the lowest layer location index parcel) for a lo- 
cation reference record parcel. 
[0115] Each of the parcels 320(LR) that contain loca- 
tion reference data 245 has a similar organization. The 
organization of a representative parcel 320(LR)(n) of lo- 
cation reference data 245 is shown in Figure 12. Each 
parcel 320(LR) of location reference data includes a da- 
ta component 521 that identifies th location reference 
record (e.g., by location key) that has the minimum lo- 
cation reference key within the parcel. This record cor- 
responds to the record pointed to by the entry in the lo- 



cation key index 247(LR). The pare I of location ref r- 
ence data 245 also includ s an offset table 545 and lo- 
cation referenc records 550. 
[0116] Th offset tabl 545 includes a list of entries 

5 546(1), 546(2), 546(3)... that correspond to each of the 
location reference records 550(1), 550(2) . . 550(n), in- 
cluded in the parcel. The entries 546 in the list 545 reflect 
the ordering of the location reference records which in 
a present embodiment are numerically ordered. Each 

10 entry 546 identifies the length 547 of its corresponding 
location reference record in the parcel. The offset table 
545 also includes, for each entry 546, data that identify 
the next location key 549. The data in the next location 
key 549 identify the location key 505 of the immediately 

is next location reference number along the roadway rel- 
ative to the location key of the entry 546. Similarly, each 
entry 546 includes data that identify the previous loca- 
tion key 551 . The data in the previous location key 551 
identify the location key of the immediately previous lo- 

20 cation reference number along the roadway relative to 
the position corresponding to the location key of the en- 
try 546. For example, referring to the illustration in Fig- 
ure 9, an entry 546 in the offset table for the location key 
for the interchange associated with "LR 12006" would 

25 identify the location key for LR1 2005 as its previous lo- 
cation key 551 and the location key for LR1 32297 as its 
next location key 549. As mentioned above, location ref- 
erence numbers are not necessarily assigned consec- 
utively along a roadway. Therefore, the next and previ- 

30 ous location keys for each location reference number 
are identified in the offset table 545. 
[0117] Following the offset table 545 in the parcel is 
the location reference record portion 550 of the location 
reference parcel 320(LR). The location reference record 

35 portion 550 includes the location records 550. Each lo- 
cation reference record 550 in the location reference 
parcel 320(LR) includes the components identified in 
Figure 11. Specifically, each location reference record 
550 includes a direction attribute (corresponding to the 

40 direction data 260(2) in Figure 1 1 ) and a list of segment 
ID's (corresponding to the list 360(1) in Figure 11). Op- 
tionally, the location reference record 550 may also in- 
clude an intersection attribute (corresponding to the in- 
tersection data 260(3) in Figure 11), 

45 

E. Programming to use location reference data. 

[0118] Another aspect of the present embodiment in- 
cludes programming that uses both the data in the traffic 

so messages 50 and the location reference data 245 in the 
geographic database 140. (This programming is re- 
ferred to herein as "location reference programming" or 
"location reference routine" 1 45.) The location reference 
programming 145 may be included as part of the navi- 

55 gation application programming 11 8 (in Figure 2) that is 
installed in and/or ex cuted by the navigation system 
110. Alternatively, the location reference programming 
1 45 may be included as part of a software interface layer 
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that resides between the navigation application func- 
tions (such as the routing function 141, the map display 
function 143, etc.) and the geographic database 140. 
Th software interface layer may also be installed in 
and/or executed by the navigation system 110. If the lo- 
cation reference programming is installed in the naviga- 
tion system 110 in the vehicle, it may be stored in a non- 
volatile computer-readable medium that is part of the 
navigation system. 

[011 9] Figure 1 4 shows a flowchart that sets forth the 
major steps in the location reference programming 145. 
In the embodiment shown in Figure 14, a receiver rou- 
tine application 707, which may be part of the navigation 
application program 118, performs certain initial steps 
and then provides an output to the location reference 
programming 145. In an alternative embodiment, the 
steps performed by the receiver routine application 707 
may be performed by the location reference program- 
ming 145. 

[0120] In an initial step (Step 71 0), a single traffic mes- 
sage 50 is received. The traffic message 50 may have 
a format similar to that shown in Figure 3. In the next 
step (Step 714), the traffic message 50 is parsed to ob- 
tain the components of the message 50, including the 
location reference number 51(1), the extent 50(4), and 
so on. These data are provided by the receiver routine 
application 707 to the location reference programming 
145. 

[0121] Using the location reference number 51(1), the 
country code 51 (3), and the location table number 51 (2) 
from the message, a location key 505 is formed (Step 
718), The location key 505 may be formed by concate- 
nating these components extracted from the traffic mes- 
sage. Using the location key 505 formed in the previous 
step, the location key index 247(LR) in the geographic 
database 140 is used to find the parcel 320(LR) of loca- 
tion reference data records that contains the location 
reference record associated with the location key (Step 
722). Next, once the parcel of location reference records 
that contains the record associated with the location key 
is identified using the location key index 247(LR), the 
parcel is accessed and read (Step 726). 
[01 22] In reading the parcel 320(LR), the parcel head- 
er, including the offset table 545, is read first (Step 730). 
Using the offset table 545 (in which the location keys 
are numerically ordered), the entry corresponding to the 
desired location key is found (Step 734). From the entry 
in the offset table 545, either the next location key 548 
or the previous location key 551 is read. Which of these 
keys (i.e., next or previous) is read depends on the di- 
rection data 50(3) in the traffic message, which defines 
the direction of traffic congestion relative from the posi- 
tion of the location reference number. Using the direc- 
tion data 50(3) and the extent data 50(4) from the traffic 
message 50, in conjunction with either the next or pre- 
vious location key from the offset table, each of th other 
location keys to which the traffic message applies can 
be determined (Step 738). The offset table may have to 



be used s veral times to identify all the location keys 
encompassed within an extent. For example, if the ex- 
tent data 50(4) is "4, " the offset table 545 is used first to 
identify the next (or pr vious, depending upon the direc- 
5 tion) location key relativ to the location key for the lo- 
cation reference number 51 (2) identified in the message 
50. Then, this next (or previous key) key is located in 
the offset table in order to identify its next (or previous 
location reference key). This process is continued until 
10 all four of the location keys (corresponding to the "4" 
identified in the extent data field 50(4) are identified. It 
may be necessary to access one or more additional par- 
cels of location reference data records if the extent data 
field 50(3) identifies a string of location reference loca- 
ls tions represented by location reference records in more 
than one parcel. In many cases however, the keys are 
repeated so that the number of parcels that needs to be 
read is kept to a minimum. 

[01 23] After all the location keys corresponding to the 

20 extent are identified, the offset table 545 is used to lo- 
cate the desired location reference data records within 
the parcel (Step 742). For each location key entry in the 
offset table, the offset into the parcel identifies the loca- 
tion within the parcel at which the data associated with 

25 the location key entry is found. For each location key 
entry, the location reference data record 550 is read 
(Step 746). Specifically, all the segment ID's associated 
with each identified location key are identified. These 
segment ID's identify all the segments that are affected 

30 by the traffic congestion in the traffic message 50. These 
segment ID's may be associated with more than one lo- 
cation reference number because the extent data 50(4) 
may identify more than one location reference number 
as being affected by the traffic congestion. This list of 

35 segment ID's 752 is then returned (Step 750) to the pro- 
gram that called it. Examples of how this location refer- 
ence programming routine 145 can be used in the con- 
text of the navigation system are provided below. 
[0124] The location reference programming 145 may 

40 return a list of segment ID's for one layer (e.g., routing 
layer 0), or alternatively, for more than one layer. In an 
embodiment in which the location reference records 260 
include only the segment ID's associated with one layer, 
such as routing layer 0, these routing layer 0 data 

45 records may be accessed first and read to obtain the 
references included in these layer 0 segment data 
records to the data records in other, higher layers. Then, 
these additional segment ID's 759 may also be returned 
to the calling application. If the higher layers include ag- 

50 gregated segments data records, references to these 
records may also be returned. The steps (756 and 758) 
included in this optional alternative are illustrated by the 
dashed lines in Figure 1 4. 

[0125] The location reference programming 145 may 
55 be writt n in any suitable programming language. In one 
embodiment, th location reference programming 145 
is written in the sam programming language as the oth- 
er functions that access and use the geographic data- 
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base. In a present embodiment, th location referenc 
programming 145 is written in C, although in alternativ 
embodiments, the location reference programming 145 
may be written in any suitable programming languag , 
such as C++, Java, or programming languages that may 
be developed in the future. 

F. Methods of operation 

[0126] According to the present embodiment, for a 
given type of location reference (such as the ALERT-C 
protocol in the RDS-TMC system) and one or more lo- 
cation references of that type, a means is provided for 
returning the entities corresponding to those references. 
For the RDS-TMC location reference type, the location 
reference would represent the RDS-TMC code, which 
is the collective encoding of the location attributes as 
noted above. The entities or records returned from the 
geographic database 141 would be segment data 
records 

[0127] Methods of using the embodiments are dis- 
closed in the following examples. 

Example 1 

[0128] This example is described in connection with 
Figure 15. In the example of Figure 15, traffic data are 
obtained at initialization of the navigation system and 
then updated continuously or at regular intervals during 
use of the navigation system. In Figure 15, at or after 
the navigation system is started or initialized (Step 807), 
a traffic data collection program 810 is executed. This 
traffic data collection program 810 may be part of the 
navigation application programming 118, the interface 
layer programming (mentioned above), or any other part 
of the navigation system. The traffic data collection pro- 
gram 810 may work in the background so that it does 
not interfere with other tasks that the end-user may call 
on the navigation system to perform. 
[01 29] The traffic data collection program 81 0 begins 
to receive traffic message broadcasts 50. These may be 
received from the receiver 1 25 in Figure 2. For each traf- 
fic message 50 received, the traffic data collection pro- 
gram 810 calls the location reference routine 145 
(shown in Figure 1 4) (Step 825). The traffic data collec- 
tion program 81 0 may have to buffer the traffic messag- 
es 50 received from the traffic broadcast system 20 until 
the location reference routine 145 is able to catch up 
with the messages. A portion of the memory of the nav- 
igation system may be provided for this purpose. 
[0130] For each traffic message 50, the location ref- 
erence routine 1 45 returns a list of segment ID'S that are 
affected by the congestion reported in the traffic mes- 
sage. The severity of the congestion from the traffic 
m ssage is associat d with the s gments and stored in 
a temporary database 818 (Steps 827 and 829). The 
data collection program 810 continues to store data that 
associates severity with segment data records until all 



the traffic messages have been obtained (Step 830). At 
this point the data collection program continues to col- 
lect traffic messages and updates the temporary data- 
base as necessary as the severity associated with seg- 

5 ments chang s (Step 831). 

[01 31 ] At any tim after all the traffic messages have 
been obtained, the temporary database 818 may be 
used by the navigation application. For example, when 
the route calculation function 141 is executed to deter- 

io mine a solution route 833, the temporary database 81 8 
may be used in conjunction with the geographic data- 
base 140. The route calculation function examines seg- 
ments from the geographic database 140 for the pur- 
pose of determining potential solution routes and deter- 

is mines whether any of the segments have severity rat- 
ings associated with them in the temporary database 
81 8. If a segment in a potential solution route has a se- 
verity weighting associated with it in the temporary da- 
tabase 818, the weighting is taken into account when 

20 comparing the potential solution route to other potential 
solution routes. If traffic is severely congested on a seg- 
ment of a potential solution route, another potential so- 
lution route may be selected. 

[01 32] In this example, the access performance of ob- 
25 taining the segments associated with traffic messages 
is not critical because the traffic data collection process 
accumulates the list of segment entities to be avoided 
in the temporary database 81 8 prior to route calculation. 

30 Example 2 

[0133] This example is described in connection with 
Figure 16. In Figure 16, traffic data 50 are not obtained 
until the route calculation program 141 is run. In Figure 

35 1 6, the route calculation program 1 41 receives input that 
includes a desired destination and an origin (Step 901). 
A traffic data collection program 903 is called. This traffic 
data collection program 903 obtains traffic messages 50 
broadcast by the traffic broadcast system 20 (Step 905). 

40 Each of these traffic messages may be temporarily 
stored in a memory of the navigation system 110. The 
traffic messages 50 may be filtered so that messages 
that pertain to locations relatively far away from potential 
solution routes are not processed. Then, the traffic data 

45 collection program 903 executes a routine 907 for each 
pertinent traffic message. 

[0134] For each traffic message 50, the routine 907 
calls the location reference routine 145 (in Figure 14) in 
order to obtain all the segment data entities (or at least 

so the ID's for all the segment data entities) associated with 
the location reference numbers) in the traffic message 
including the location reference number explicitly spec- 
ified in the traffic message as well as those location ref- 
erence numbers which are implicitly specified by the ex- 

55 tent data included in the traffic message. Using the list- 
ing 752 of s gment data entiti s (or the ID'S th reof), 
th severity of th traffic congestion included with the 
traffic message is associated with each of th se s g- 
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ment data entities (or ID's) (at Step 913). This associa- 
tion of severity with s gment ID's is stored in a tempo- 
rary database 916 (at Step 915). 
[01 35] Once all the pertinent traffic messages are ob- 
tained, the route calculation function 141 proceeds to 5 
determine a solution route 921 (Step 917). In the proc- 
ess of determining a solution route, the temporary da- 
tabase 91 6 of weighted segments is used in conjunction 
with the geographic database 140. When a portion of a 
potential solution route being calculated by the route cal- 
culation function 141 includes one of the segments as- 
sociated with a severity weighting in the temporary da- 
tabase 916, the weighting is taken into account when 
comparing the potential solution route to other potential 
solution routes. The severity weighting may indicate that 
the traffic congestion is so bad that the segment should 
be avoided entirely. Alternatively, the severity may be 
relatively light so that segments that include traffic con- 
gestion may still be used in a potential solution route. 

G. Alternative embodiments. 

[01 36] In alternative embodiments, some or all of the 
navigation application programming or functions per- 
formed by the navigation system may be performed re- 
motely. For example, some or all of the navigation ap- 
plication programming functions may be performed by 
a service provider to which the vehicle has a wireless 
communication link. (The service provider is not neces- 
sarily associated with the traffic broadcast system.) In 
such an alternative, the user's input may be transmitted 
to the remote service provider where the navigation 
function is performed and the result transmitted back to 
the vehicle. The location reference programming and/or 
the data collection programming may be located either 
in the vehicle or may be accessed remotely. 
[0137] In another alternative, some or all of the geo- 
graphic database 140 may be located remotely, with a 
service provider for example, and accessed by the nav- 
igation system in the vehicle via a wireless communica- 
tion link. The location reference records may be located 
either on a computer readable medium in the vehicle or 
may be located remotely and accessed via a communi- 
cations link. 

[0138] In another alternative, some or all of the loca- 
tion referencing data may be downloaded as needed via 
a wireless communication link and stored in the vehicle 
on a separate, writable media located in the vehicle, or 
alternatively, the location reference data may be stored 
in a table in a memory (such as a RAM) in the vehicle. 
In this embodiment, the navigation programming in the 
vehicle that uses the location referencing data accesses 
the data from the separate medium. An advantage of 
this embodiment is that the location referencing data 
can be updated as needed. Another advantage is that 
n w traffic messag systems can be accommodated 
readily. To ke p storage at a minimum the data could be 
read only for a limited geographic coverage area. 



[01 39] In a further alternative, a primary sourc of lo- 
cation refer ncing data can bestored with the geograph- 
ic database and updates to the location referencing data 
can be downloaded and stored on a separate m dium. 
In this embodiment, the programming that uses the lo- 
cation referencing data uses both the primary location 
reference data and the updated data. 
[01 40] In another alternative embodiment, the receiv- 
er that receives the traffic messages and provides the 
traffic messages to the programming that parses the 
traffic message may be part of the navigation system 
110 (as shown at 125 in Figure 2) or alternatively, the 
receiver may be a stand-alone unit or a unit associated 
with another kind of equipment. This alternative embod- 
iment is shown at 1125 in Figure 17. If the receiver is 
not part of the navigation system 11 0 as shown at 1125 
in Figure 17, the receiver 1125 has an output port 1127 
that can be coupled to an input port 1129 on the navi- 
gation system 110 in order to allow the transfer of data, 
such as the traffic messages, from the receiver 1125 to 
the navigation system 110. The ports on the receiver 
and on the navigation system, 1127 and 1129, may pro- 
vide for a direct connection or alternatively may provide 
for connection by cabling 1131. In other respects, the 
navigation system and the geographic database are 
similar or the same as in the previously described em- 
bodiments. 

[0141] In alternative embodiments, the geographic 
database 1 41 may include location reference data that 
supports traffic broadcast messages from systems oth- 
er than the RDS-TMC system. Examples of such other 
systems include GATS, VICS, and ITS Datum, as well 
as proprietary systems, and systems that may be devel- 
oped in the future. Such other systems may include 
messages that are similar to the messages in the RDS- 
TMC system or may include different kinds of messag- 
es. These different kinds of messages may include a 
location referencing system, like the RDS-TMC system, 
or may include other kinds of location referencing. 
These different kinds of systems may include extent da* 
ta that implicitly identify other locations, or alternatively 
all locations may be explicitly identified. 
[0142] In another embodiment, the geographic data- 
base may include location reference data that supports 
more than one kind of traffic broadcast messaging for- 
mat. For example, the RDS-TMC system as well as 
some other system may be supported. In some regions, 
there may be more than one kind of traffic broadcast 
system, each with its own kind of message format, lo- 
cation referencing numbers, and so on. Under these cir- 
cumstances, the geographic database may include sep- 
arate sets of location reference data records, each 
formed with separate location keys. These separate 
sets may be stored in the geographic database 141. 
[01 43] I n a navigation system that supports mor than 
one kind of traffic broadcast m ssaging format, or traffic 
broadcast systems in addition to the RDS-TMC system, 
the geographic database may support a qu ry from the 
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navigation application program to identify the kinds of 
real time traffic broadcast systems that are support d. 
The query returns an identification of the traffic broad- 
cast systems whose location reference data are includ- 
ed in or supported by the geographic database. In these 5 
kinds of systems that support multiple traffic messaging 
formats, programming may also be provided in the nav- 
igation system that allows a selection of the traffic mes- 
sage format. The selection process may be automatic 
or alternatively, the selection process may be made by 
the end user. Support for multiple traffic broadcast for- 
mats may be useful for vehicles that travel to different 
cities that have different traffic broadcast system for- 
mats. 

[0144] According to another alternative embodiment, 
location reference data entities may be used in the ge- 
ographic database to utilize numbering references from 
systems other than those that broadcast traffic messag- 
es. For example, there are organizations or entities that 
provide services related to certain types or classes of 
points-of-interest. Examples of such organizations in- 
clude ticket sellers who sell tickets to various events (e. 
g., theater, sports, music, movies, comedy, and so on) 
in a metropolitan area. Each of the venues for which tick- 
ets are available may be identified by the ticket seller by 
a reference number. According to this alternative em- 
bodiment, the geographic database includes location 
reference data entities that relate the reference num- 
bers used by the ticket seller to data included in the ge- 
ographic database. In this embodiment, each location 
reference data entity in the geographic database corre- 
sponds to one of the reference numbers used by the 
ticket seller to identify a venue. Each location reference 
data entity identifies a corresponding point-of-interest 
data entity record in the geographic database which cor- 
responds to the location as the venue. The navigation 
application may use these kinds of location reference 
data entities in a manner similar to the way it uses traffic 
message information. The navigation application re- 
ceives data from the ticket seller either directly or indi- 
rectly. The data may be received by wireless or non- 
wireless means of communication. The data from the 
ticket seller identifies venues by the identification num- 
bers assigned by the ticket seller. The data may also 
include performance times, ticket availability, ticket pric- 
es, programs, and so on. The navigation application us- 
es the location reference data entities to relate the in- 
formation received from the ticket seller to the point of 
interest data entities in the geographic database. The 
user can then access the information received from the 
ticket seller in conjunction with use of the point-of-inter- 
est data in the geographic database. The user can use 
the data from the ticket seller as further criteria when 
searching the geographic database. For example, the 
user can s arch for theater performances within 25 
miles and that start within th next 2 hours. Oth r kinds 
of syst ms to which the location reference number can 
be used includ hotel chains, restaurant organizations, 



real estat brokers' offices, and so on. 
[0145] It is intended that the foregoing d tailed de- 
scription b r gard d as illustrative rather than limiting 
and that it is understood that the following claims includ- 
ing all equivalents are intended to define the scope of 
the invention. 



Claims 

1 . A method of operating a navigation application pro- 
gram comprising: 

receiving broadcast traffic messages that in- 
clude data that indicate traffic conditions at lo- 
cations on roads in a geographic area; 
extracting data components from said traffic 
messages, wherein said data components in- 
clude data that identify locations on said roads 
to which said messages relate; and 
searching a geographic database using said 
extracted data components to find data entities 
in said geographic database that represent ge- 
ographic features that correspond to said loca- 
tions. 

2. The method of Claim 1 further comprising the step 
of: 

associating the data in said traffic messages 
that indicate traffic conditions at locations to those 
data entities in said geographic database which had 
been identified in said step of searching as corre- 
sponding to said locations. 

3. The method of Claim 2 wherein said step of asso- 
ciating the data in said traffic messages to data en- 
tities in said geographic database is performed prior 
to performing a route calculation function. 

4. The method of Claim 2 wherein said steps of ex- 
tracting, searching, and associating are performed 
until all pertinent traffic messages have been proc- 
essed. 

5. The method of Claim 2 wherein said step of asso- 
ciating the data in said traffic messages to data en- 
tities in said geographic database is performed as 
part of a route calculation function of said navigation 
application program. 

6. The method of Claim 2 wherein said steps of ex- 
tracting, searching, and associating are updated as 
new traffic messages are received that indicate 
changed traffic conditions. 

7. The m thod of Claim 1 further comprising the step 
of: 

after finding data ntities in said geographic 
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database that represent geographic features that 
correspond to said locations, weighting said data 
entities according to the data that indicates traffic 
conditions. 

8. The method of Claim 1 wherein said geographic da- 
tabase is located in an on-board navigation system. 

9. The method of Claim 1 wherein said navigation ap- 
plication program is installed in a navigation system 
installed in a vehicle. 

10. The method of Claim 1 wherein said traffic messag- 
es are broadcast on the Radio Data System-Traffic 
Message Channel. 

11. The method of Claim 1 wherein said traffic messag- 
es conform to a standard format for ALERT-C mes- 
sages established in the RDS-TMC system. 

12. The method of Claim 1 wherein said navigation ap- 
plication program is installed in a non-vehicle. 

13. The method of Claim 1 wherein said step of receiv- 
ing is performed in a receiver, and whereii said step 
of searching a geographic database is performed in 
a navigation system which is separate from said re- 
ceiver. 

14. A method of operating a navigation system com- 
prising: 

in an in-vehicle navigation system, receiving a 
plurality of broadcast traffic messages from a 
traffic broadcast system that broadcasts said 
traffic messages, wherein 6ach of said traffic 
messages includes a plurality of data compo- 
nents including a first data component that 
identifies a location to which the traffic message 
relates and a second data component that in- 
dicates a severity level of traffic congestion at 
said location; 

in said in-vehicle navigation system, searching 
a geographic database used by said in-vehicle 
navigation system to locate data entities in said 
geographic database that are associated with 
the location identified by said first data compo- 
nent; and 

associating said located data entities with the 
severity level of said second data component. 

1 5. The method of Claim 1 4 wherein said first data com- 
ponent is comprised of a location reference number 
that identifies said location. 

16. The method of Claim 14 further comprising th step 
of: 

after receiving said plurality of broadcast traf- 



fic messages, extracting first data components and 
second data components from said traffic messag- 
es. 

5 17. The method of Claim 14 wher in said data compo- 
nents include data that indicate succ ssive adja- 
cent locations to which reference numbers have 
been assigned. 

10 18. A geographic database for use with a navigation 
system used in conjunction with traffic messages 
broadcast by a traffic condition broadcast system, 
said geographic database comprising: 

15 data entities of a first type that represent geo- 

graphic features in a geographic region, includ- 
ing portions of a road network; and 
data entities of a second type that associate lo- 
cation references included in said traffic mes- 

20 sages to pluralities of said data entities of said 

first type, 

whereby the navigation system using said ge- 
ographic database in conjunction with traffic 
messages broadcast by the traffic condition 
25 broadcast system can incorporate information 

from said traffic messages when using said ge- 
ographic database. 

1 9. The invention of Claim 1 8 wherein said data entities 
30 of said first type and said data entities of said sec- 
ond type are organized into a plurality of parcels 
each of which includes a plurality of data entities of 
said respective types. 

35 20. The invention of Claim 1 8 wherein said geographic 
database is separated into parcels each of which 
includes a plurality of data entities. 

21. The invention of Claim 1 8 wherein said geographic 
40 database is comprised of separate types of geo- 
graphic data. 

22. The invention of Claim 21 wherein said separate 
types of geographic data include routing and carto- 

45 graphic. 

23. The invention of Claim 1 8 wherein said geographic 
database is stored on a computer readable medi- 
um. 

50 

24. The invention of Claim 1 8 wherein said geographic 
database is stored on one of a CD-ROM disk, a DVD 
disk, and a hard disk. 

55 25. The invention of Claim 1 8 wherein said data entiti s 
of said first typ represent segments of roads. 

26. The invention of Claim 18 wh rein said data entiti s 
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of said first type represent segments of roads, in- 
cluding segments of roads that lead into locations 
along said road network that are represented by 
said location references in said traffic m ssages. 

27. The invention of Claim 18 further comprising: 

an index that relates location references to 
said data entities of said second type. 

28. The invention of Claim 1 8 wherein said data entities 
of said second type are arranged numerically in a 
plurality of parcels and wherein said geographic da- 
tabase further comprises: 

an index that identifies, for a first data entity 
of said second type in each of said plurality of par- 
cels, the one of said plurality of parcels in which said 
first data entity of said second type is located. 

29. The invention of Claim 1 8 wherein said location ref- 
erences included in said traffic messages represent 
interchanges along roads. 

30. The invention of Claim 18 wherein at least part of 
said geographic database is located remotely. 

31 . The invention of Claim 1 8 wherein said data entities 
of a second type are located remotely. 

32. The invention of Claim 1 8 wherein said data entities 
of a second type are downloaded to the navigation 
system from a remote location. 

33. A method of forming a geographic database that 
can be used in a navigation system that also uses 
traffic messages broadcast by a traffic broadcast 
system that identify locations along roadways with 
location reference numbers, the method comprising 
the steps of: 

for each location reference number, identifying 
a first group of data entities in said geographic 
database that represent portions of a roadway 
that correspond to the location identified by 
said location reference number; 
identifying a second group of data entities in 
said geographic database that represent por- 
tions of the roadway leading into the location 
identified by said location reference number; 
and 

forming a plurality of location reference data 
entities that identify, for each location reference 
number, said first group and said second group 
of data entities. 



message location reference data of a first type that 
can be used with a respective first type of traffic 
message broadcast system and traffic message lo- 
cation reference data of a second type that can be 
5 used with a respective second type of traffic mes- 
sage broadcast system, the method comprising the 
steps of: 

selecting one of said first type of traffic broad- 
10 cast system and said second type of said traffic 

message broadcast system; 
receiving traffic messages broadcast by a traf- 
fic message broadcast system of said selected 
type; and 

is using said location reference data in said geo- 

graphic database that corresponds to said se- 
lected type to associate data in said traffic mes- 
sages received from said traffic message 
broadcast system to said data entities that rep- 

20 resent geographic features in a geographic ar- 

ea in said geographic database. 
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34. A method of operating a navigation application pro- 55 
gram that uses a geographic database that includes 
data entities that represent geographic features in 
a geographic area and further that includes traffic 
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